perm filename RAND.OLD[RDG,DBL]2 blob
sn#614606 filedate 1981-09-28 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00017 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00003 00002 ∂23 Mar 1981 1512-PST ROLANDA Protocol fle
C00043 00003 ∂14 Apr 1981 1617-PST RICK at RAND-AI Re: The real message is
C00044 00004 ∂16 Apr 1981 1004-PST RICK Planners' homework 16-apr-81
C00063 00005 ∂17 Apr 1981 1228-PST RICK Planners' Workbench project-plan for remainder of FY81
C00076 00006 ∂6 May 1981 1538-PDT BILL workbench.todo homework
C00097 00007 ∂8 May 1981 1320-PDT Keith Wescourt <WESCOURT> PROJECT PLAN HW
C00118 00008 ∂18 May 1981 1155-PDT Keith Wescourt <WESCOURT>
C00129 00009 ∂25-May-81 1407 barbara at RAND-UNIX Re: Relns connecting Rationale & PlanSteps
C00134 00010 ∂19-Jun-81 1236 RICK at RAND-AI revised retrieval specifications
C00144 00011 ∂TO Keith, Greiner (12:05 29 June)
C00146 00012 ∂29-Jun-81 1259 Keith Wescourt <WESCOURT at RAND-AI> Re: Data for Retrieval
C00148 00013 ∂24 Jul 1981 1112-PDT <WESCOURT> Re: Minor changes to Entry/Retrieval Interface Specification
C00158 00014 ∂TO Wescourt, Rick 17:05 24-Jul
C00166 00015 ∂TO Wescourt, Rick 18:25 24-Jul
C00173 00016 ∂TO wescourt at RAND-AI, rick at RAND-AI 14:24 29-Jul
C00189 00017 ∂TO WESCOURT (CC RICK) 11:45 11-Sept
C00192 ENDMK
C⊗;
∂23 Mar 1981 1512-PST ROLANDA Protocol fle
To: Greiner
cc: Rick
Russ,
Rick asked me to send this file to you:
1
2 mon feb 16 14:22:39 pst 1981
3
4 take either saturday or sunday.
5 the route:
6 pch to topanga cyn
7 topanga to mulholland
8 mulholland to lake vista drive
9 as soon as you predict you'll get too tired to return home,
10 return, or continue to:
11
12
13 lake vista drive down to the lake
14 return:
15 lake vista drive to mulholland
16 mulholland to topanga
17 lunch: eat at one of the places around the lake, lean up against bank
18 if you return prior to reaching lake, eat lunch at tapia park down las
19 virgenes 1/4 mile
20 north on topanga to dumetz
21 country club on dumetz which is novel to him
22 east on dumetz to serrana
23 north on serrana to ventura blvd.
24 east on ventura blvd to sepulveda blvd
25 back home
26 rose & walgrove (.5 mi east of lincoln) in venice
27 right near the sm airport
28 he says it's too long! needs shortening
29
30
31 plan escape routes
32 plan phone calls
33
34
35 ----------------------------------------------------------------
36 2/18 rationale
37
38 why the mon feb 16 plan was too long: based on comparison with
39 a ride that's closely related to this plan and which he's done before,
40 i.e. if you get rid of the side trip on mulholland and replace
41 topanga by old topanga. however, this trip might be too hard in current
42 physical condition of norm.
43 from 1, this suggests getting rid of
44 going up, old topanga is more difficult but infinitely preferable:
45 less traffic,more to look at.
46 amend the plan to go up old topanga, because of 3 and we know he
47 nice things to look at.
48 look for ways to amend the mon 2/16 plan to shorten it.
49 like the basic plan: pch through the mountains, down to valley,
50 and back via sepulveda. so going to change details within this overal
51 form.
52 some changes we can make:
53 a. shorten the part of the trip west of topanga to the lake,
54 by getting rid of that part of the trip.
55 b. would this be too long? no, he can't say that, but does
56 say it might be.
57 c. thus, let's cut out malibu lake and tapia park.
58 d. what things were these things trying to achieve?
59
60 at this point let's search the rationale for lake and tapia.
61 lunch place: tapia and malibu lake
62 urinating facilities: tapia
63 review the plan rationale for the part of plan
64 from pch to sepulveda for a lunch place.
65
66 for each piece of plan, check the rationale for lunch concepts.
67 lunch stop needs something nice to look at
68 lunch needs a natural or artificial back rest for sitting
69
70
71 regarding urinating:
72 almost anywhere on old topanga will do after you start to rise
73 add to plan to pee on old topanga after it starts to rise
74
75
76 norm is willing to take a plan that doesn't specify where to lunch.
77
78 so maybe the novel country club would be a good place to eat.
79 he's not averse to risk of this sort.,
80 but golf courses around here usually have fences around them.
81 this seems to eliminate the golf course for lunch.
82 boy scout camp on red rock road looks interesting. it's not a big
83 diversion. maybe it'll do for lunch.
84 keith's intuition is that there'll be a nice place to eat around
85 there and norm can lean up against a tree.
86 norm's never been on red rock road. it looks nice he says.
87 it is hilly.
88 patch the plan: let him go out on red rock road for upto 20 minutes
89 looking for a nice place to eat. if he can't find one, turn around and
90 stop near the country club somewhere for eating.
91 barbara recommends red rock
92 ever been on calabassas peak motorway? norm says motorways are unpaved.
93 for a few months, he's been unwilling to take unpaved roads.
94 is red rock paved? it has the same symbology on the 1971 ed of
95 thomas bros la street map as calabassas peak motorway.
96 if it's paved, it's a good idea. from the map norm believes it is
97 paved, but if it were paved, he'd know about it, and since he doesn't
98 know about it, he doubts it is paved. overall, he assumes it is partly
99 paved.
100
101 he'd be willing to go on an unpaved street for a short distance,m
102 but not down hill.
103 but since it's hilly, it'd have to be downhill at least one way.
104 how about walking to lunch? he's not averse to chaining the bike
105 to a tree. he is averse to walking more than 1/8 mile.
106 1/8 mi doesn't seem to be far enough to reach lunch on red rock road.
107
108 keith complained about the lack of relevant infor on the map for
109 the planning task.
110
111 lunch at dumetz: would it be too late? depends on the time the
112 plan starts.
113
114 9am would be a reasonable time to start.
115
116 if he started at 9, he could eat lunch at dumetz. it wouldn't
117 be too late.
118
119 at the intersection of old topanga & mulholland hiway, there's
120 a high school. they generally have fields, etc., and may make a
121 nice place to eat.
122
123 keith recommended eating at that high school (see 28)
124
125 barbara thought it wouldn't satisfy the seating or view requirements.
126
127 norm hasn't been to calabassas high school.
128
129 quite often high schools on saturdays are nice places to eat, e.g.
130 soccer games, etc.
131 on sundays, norm thinks they tend to be dull.
132 barbara says both saturday and sunday at paul revere junior high
133 things happen.
134
135 so they recommend the high school for lunch, and that means
136 the plan is restricted to saturday.
137
138 patch the plan to restrict it to saturday and lunch at the high school.
139
140 possible options fromthis point, after lunch:
141 can continue on old topanga from high school until it hits mulholland
142 and then go right and take it to topanga, or can
143 go back to mulholland hiway to mulholland drive and take that to topanga.
144 these roads define a triangle of about 1.25 miles on a side, and the
145 high school is in the center of that triangle.
146
147 work on getting him back:
148
149
150 sfv map shows greater detail on the triangle in 37.
151 the high school fronts on mulholland hiway, rather than old topanga road.
152 thus, of the two alternatives in 37, suggest that norm turn on mulholland
153 hiway rather than continuing on old topanga road.
154 at the intersection of hiway and old topanga road, norm should use his
155 judgment about the best way to get to the high school.
156
157 ventura blvd between serrana ave and sepulveda is not a pleasant ride.
158 what about streets that are deeper (more north) in the valley for
159 more pleasant ride.
160 what about victory, which is 2 mi further north. less cars, good.
161 smaller shoulder than ventura.
162
163 oxnard is nicer. good things to look at and nicer than
164 ventura or victory, as in 40.
165
166 patch to plan: from serrana, continue across ventura by joggin
167 to right onto de soto, under the ventura fwy. take de soto to oxnard st.
168 right on oxnard. oxnard to tampa ave, left on tampa, right on topham st.
169 topham to white oak. topham changes names back to oxnard st.
170 continue on oxnard st to louise ave. right on louise, lousie to
171 burbank blvd.
172
173 how is burbank blvd, where it goes through the sepulveda flood
174 control basin? norm doesn't know.
175
176 44contd. turn left on burbank blvd to sepulveda blvd. cross under
177 405 (or under). right on sepulveda, go south.
178
179
180 presumably sepulveda blvd is the only way back at that point other
181 than the freeway.
182
183 there are many ways from valley up to the top of the hill
184 (the santa monica mtn).
185
186 havenhurst/calneva, a couple of miles west of sepulveda,
187 is an interesting way from the valley up the hill.
188
189 patch the plan: louise to burbank to sepulveda gets changed
190 to... right onto havenhurst from burbank. havenhurst across ventura
191 blvd, uphill, until calneva. left on calneva. calneva to mulholland
192 drive. left on mulholland to sepulveda, then south on sepulveda.
193
194 can't get directly from mulholland to sepulveda; they don't
195 intersect.
196
197 oxnard is only .5 mi north of ventura, so the oxnard detour
198 adds only 1 mile. it's completely flat, and will probably be less
199 wear and tear than riding on ventura bl.
200
201 start working on best way back from sunset & sepulveda to home.
202 bundy and centinela are bad: narrow, no shoulder, lots of traffic.
203
204 suggest: right on sunset from sepulveda
205
206 sepulveda south of sunset has no traffic but no view either.
207
208 ohio has a bike path.
209
210 patch: sepulveda, right on ohio, left on barrington.
211 barrington to gateway, right on gateway to
212
213 must get around sm airport, two possible ways.
214 bundy or ocean park or pearl st are alternatives.
215
216 redo 56
217 patch: sepulveda, right on ohio, left on barrington.
218 barrington to gateway, right on gateway to
219 ocean park, ocean park to 21st, lefton 21st,
220 continue to dewey st where he makes a left.
221 norm considers this home.
222
223 big problem with the plan is calneva, it's too steep,
224 given the amount of other things going on,.
225
226 to avoid calneva, you don't want to go on the south side of
227 ventura.
228
229 norm denies 58,but keith says it would take lots of street changes
230 to do, and norm previously said he didn't want to have to handle complicated
231 plans. that's why 58 is the way it is.
232
233 patch: south on havenhurst, left onto ventura blvd, go approx 1 mi
234 to haskell avenue, right on haskell and it will eventually turn into valley
235 vista, and thence to sepulveda.
236
237 going south on sepulveda from that general vicinity, it's
238 better to get off burbank before crossing havenhurst otherwise you'll
239 have to go through lots of freeway underpasses and add distance.
240 inferring that there'll be traffic near freeways, freeway exits, and
241 oxnard is near the freeway around there.
242
243 in generally, there's a tension between simplifying the plan to
244 lots of turns etc vs. minimizing traffic.
245
246 biggest current problem is going up topanga from ocean on saturday
247 morning when there's lots of traffic coming to the beach.
248
249 in norm's present condition, there's no way other than topanga
250 up to that part of the mountains without going out to malibu, which
251 is too far west.
252
253 basic conflict: up topanga on saturday is unacceptable; lunch at
254 high school on sunday, would be acceptable assuming he can get in.
255
256 patch: switch the plan to sunday.
257
258 the current big problems:
259 need to provide for rand stop
260 provide for equipment malfunction
261 provide for water along the way
262 not enough plans for urinating along the way
263
264
265
266
267
268
269 patch in plan: topanga to old topanga, old topanga to mulholland
270
271
272
273
274
275
276
277 hiway, east back to topanga canyon, north to dumetz, then as per 2/16
278 plan.
279 lake callabasas doesn't exist as far as norm knows
280 considering sending him up old topanga to lake callabasas to shorten the
281 trip
282
283 ---------------------------------------------------------------------
284 2/16 rationale
285 there are urinating facilities at tapia park
286 limit a ride to 6 hrs total elapsed time
287 the length of daylight constrains the trip, wants to go in daylight
288 the ideal temperature is 60 degrees
289 temperatures below 90 is okay
290 even 40- degrees at low end is okay
291 speed is 10-15 mph on flat surface, including traffic delays
292 we derived his speed up mandeville cyn road is 7.5 mph
293 he's not in the best of shape right now
294 all these things led us to a round trip of around 45 mi
295 tuna canyon has been closed for two years, and it's too steep
296 piuma climbs from las virgenes to rambla pacifica
297 rambla pacific is very steep for descent, too steep if the rest of ride
298 was hard
299 lunch stop needs something nice to look at
300 lunch needs a natural or artificial back rest for sitting
301 urinating needs a restroom or not too public place
302 nice beach day, pch from malibu to santa monica is unpleasant due to
303 traffic from surfboarders, in afternoon
304 on non-sundays, topanga has excessive traffic
305 theorem: getting back from santa monica mountains on the weekend requires
306 an inland route to avoid these conditions
307 doesn't like descending topanga canyon in traffic because it's grueling
308 steep descents require resting places periodically (not topanga, but
309 rambla pacifica)
310 tuna canyon was steepest grade in west la county
311 good view at mulholland and malibu canyon (purple cows)
312 lunch place: tapia park below mulholland
313 lunch place: malibu lake
314 dirt roads are out, unless very short
315 doesn't like riding in flat places, such as san pedro
316 coast bicycle path has too many pedestrians et al in the afternoon
317 he likes hills
318 6am in the morning is too cold in this season
319 map distance measurer is 4.4 mi per inch on the la & vicinty map according
320 to kw's calculation
321 coast hiway to malibu from sm is perfectly flat
322 in his current condition, he doesn't think he can do the whole trip
323 which was rand to topanga, to mulholland, to malibu cyn, and
324 back through valley.
325 but the trip was generally nice anyhow
326
327
328 -----------------------------------------------
329 2/20
330
331 coast hgh to top to old top to calabassas hs to mulholland to
332 top to dumetz to serrana jog to right to desoto
333 north to oxnard east to topham=oxnard right on whiteoak
334 left on burbank to havenhurst left on ventura right on
335 haskell=valley vista right on sepulveda...
336 sepulveda, right on ohio, left on barrington.
337 barrington to gateway, right on gateway to
338 ocean park, ocean park to 21st, lefton 21st,
339 continue to dewey st where he makes a left.
340 norm considers this home.
341
342 the current big problems:
343 need to provide for rand stop
344 provide for equipment malfunction
345 provide for water along the way
346 not enough plans for urinating along the way
347
348
349 norm: if i go north, must stop at rand either coming or going
350
351 norm: early in am must urinate more often; cannot wait until old topanga
352
353 norm: where to urinate aftyer old topanga--need one more
354
355 norem: need to stop to wash once, depending on how hot
356
357 norm: carried water too prescious to wait on hot days
358
359 norm: might not be hot in near future
360
361 rick: been hot last few days
362
363 norm: wash stop also necessary to refresh water bottle
364
365 norm: one water bottle on cool day, more on hot day
366
367 if can fix bike myself (e.g., flat tire) need time to
368 fix and get home before dark
369
370 if cannot fix myself, may be immobile
371 for going up
372 for going up or down
373
374 try to plan route with only one steep uphill
375 can push bike up one mild uphill
376 walking is hard
377 route too far to walk all the way home
378 bicycle could be fixed at bike shop if near enough
379 can call for help
380 can't call from san fernando valley
381 wife can't drive that far--too far
382 but she could come if absolutely necessary--very unlikely
383 must be coordination with wife for emergency calls
384 daughter drives, but have never used her
385 3-4 bicycle shops on ventura between top and sepulveda
386 some shops on sunday
387 phone book at every phone booth in valley
388 many phone booths on ventura
389 can coast downhill from mulholland & top to top & ventura
390 if chain breaks, can get to coast highway
391 most frequent malfunction- flat tire, fix myself
392 carry spare tire, 2 spare tubes, pump
393 takes half hour in dirty clothes to change tire, longer in clean cloth
394 norm knows route time from experience
395 this route takes 3-4 hours, not including stops
396 prefers 2 hours rest
397 worst thing would be getting hit by car
398 precautions too detailed to worry about
399 most likely problem that could add delay: flat tire
400 next: too tired to proceed safely
401 or non-repairable equipment malfunction (e.g., broken chain)
402 chain has broken 4-5 times
403 doesn't carry universal link because doesn't know how to
404 take apart chain right, tried once and broke it
405 gear shift cables can break
406 doesn't carry spare cables because can't/won't fix self
407 normally just adjust mechanism so remains in low gear+>
408 get home, but slowly
409 carry screw driver, wrench, tire iron, etc.
410 break cable broke once
411 couldn't gop down topanga or ride bicycle without break cable
412 above suggests need bike shop on valley side of hill
413 under plan, would never be more than mile away
414 on sunday, 4 miles between top & sep => could be further
415 norm suspects 3-4 miles
416 he would walk
417 15 minutes to walk mile => 1 hour to walk 4
418 only thing worse is handbreak breaking
419 norm: highly unlikely and would call for help
420 takes bag full of dimes
421 rick wants norm to take nickels and quarters in case dime slot jammed
422 longest current stretch with no phone is not too long
423 longest (time) stretch with no potty is from house to beginning
424 of unsettles old top (1.5-2 hours) at difficult time of day
425 therefore, should go to rand on way out
426 can pee at rand
427 can pee at public potty on coast highway
428 norm always carries catheter
429 needs to pee after lunch--at school
430 school is not far from ventura
431 needs to refill water bottle in case hot day
432 can stop at gas stations to fill bottle if open
433 they close on sundays
434 there is a restaurant intersection vent and topo open on sundays
435 too far? no it's all downhill
436 must lock bioke to go in restaurant
437 patch plan: pee at vent/top restaurant, get water, fill bottle, clean face
438 if hs yard open, might have fountain for splashing, etc.
439 hs yard might be closed on sundays
440 it's a county school
441 might have field open
442 norm won't climb fence
443 needs second source of water in case hot day
444 never has run out of water on way up old top
445 always fills water bottle before goes up
446 can fill it at beach potty
447 patch plan: fill water bottle at beach potty
448 needs to pee after top/vetn at least once near sepulveda
449 many gas stations near there
450 prefers not to pee in gas stations
451 not many places on sepulveda where can pee
452 many public parks where can pee
453 parks better than gas stations for peeing
454 gas stations are incredibly dirty
455 prefer not to touch door handle in gas station
456 plan patch: when on burbank, stop at sepulveda recreation area too pee
457 norm wants to take a side trip to the model airport
458 he prefers watching female roller skaters over male model fliers if hot day
459 need potty this side of mountain...just in case
460 va cemetery has nice potty--immaculately clean
461 time estimate
462 3-4 hr for bicycling
463 2 hr side trips and rest, including peeing
464 1 hr to walk to repair shop
465 1 hr for repair
466 2 hr for repair shop enough for self repair
467 max elapsed time = 8 hours +← stop at rand = 1 hr or less
468 max time = 9hr
469 est is too long
470 once reach bottom of hill on sepulveda, if it's too dark can call wife
471 earliest come to rand=8
472 best time to leave rand & start current trip depends on temp
473 plan patch: arrive at rand 7:30
474 because it's cold in morning, don't want to start too early
475 earlier better, but not if too cold
476 want to leave time for other things
477 depart rand by 8:30
478 1 hour more than enough & want to get on road as soon as poss.
479 reach hs no later than noon
480 whole trip only takes 3-4 hours
481 if doesn't reach halfway point by 3 hours, something wrong
482 reach vent-sepulveda by 3
483 3 hours for third of trip + lunch is plenty
484 if don't get there in time, stuck
485 correction: vent/sep by 4
486 because if all goes well takes 2 hours to get home from there
487 dark by 6:15
488 if doesn't get there by 4
489 can't call naomi or walk
490 doesn't know if daughter will be home then
491 could but rarely takes taxi
492 rick won't be there 2/22
493 nothing like this has happened before
494 norm would call naomi & ask her to find someone else
495 otherwise taxi to sep&sunset
496 arrive home by 6
497 if fall behind schedule on this side of mountain, return home
498 if fall behind on that side,
499 do not take trip if rains
500 if rick picks up norm, he should pick up faucet
501 norm will take care of clothes and newspapers
502 clothes must suit weather
503 if cold before 9, take newspapers because disposable
504 norm doesn't know what naomi is doing any sunday
505 patch plan:
506 coordinate to reach naomi at 3 or 4
507 norm believes can do
508 be at phone at 3 or 4
509 should know by 3 if falling behind 4 deadline
510 assume, with no malfunction, will reach sep & vent by 3
511 assume, with malfunction, will reach sep & vent by 4
512 if above fails, take taxi to whatever point necessary to get home
513 take $20
514 will cover taxi fare
515 but may need more if repairs
516 usually carries only dimes & credit cards
517 take $50
518 he doesn't want to
519 take $20
520 what if it rains during trip?
521 doesn't carry rain suit
522 doesn't have suitable one
523 usually, if it rains, he takes easiest route home
524 can't really ride in rain suit
525 gortex would work
526 doesn't want to spend money on gortex
527 problem trivial compared to hand break not working when wheels wet
528 riding in rain in certain conditions unacceptable for long period
529 rain is problem only in afternoon, after 4
530 unlikely to forecast rain
531 rick thinks forecast overestimate rain chances
532 norm would go if chance of hard continuing rain at top of topanga = 5-10%
533 this is worst possible rain
534 norm won't go with any chance of rain
535 rain info from weather service -- not reachable when rain predicted
536 flight service provides useful info only 10% of time
537 patch plan: go only if 0% perceived prob rain
538 norm doesn't want to get wet
539 norm doesn't want to ride down top with wet rims
540 patch plan: norm will plan tactics
541 need route sheet
542 patch plan: night ahead, norm should prepare route sheet
**************
Rolanda
-------
---------------
-------
∂14 Apr 1981 1617-PST RICK at RAND-AI Re: The real message is
To: CSD.GREINER at SU-SCORE
cc: greiner at RAND-AI, RICK at RAND-AI
In-Reply-To: Your message of 14-Apr-81 1318-PST
I'll send you a more detailed problem statement for the project before
leaving for this weekend. Then, I'd like to have you down at rand in
the first week of may to attend a planners' pencil planning meeting.
Either weds or frid would be best. I expect the stuff you are doing
will get along fine for three weeks without direct interactions.
Let me know if you feel otherwise.
Cheers,
Rick
-------
∂16 Apr 1981 1004-PST RICK Planners' homework 16-apr-81
To: bill, greiner, wescourt, barbara at RAND-UNIX, norm at RAND-UNIX
cc: rick
Here's my entry:
0<RICK.PLANNER>PENCIL.HOMEWORK.1 10-Apr-81 10:23:16, Edit by RICK
The question: Is the pencil better/worse/potentially better than
using the protocol?
Answers:
BETTER:
> because it identifies early what the planners wound up believing,
rather than their initial or intermediate ideas
> because it helps answer questions about hypotheticals the replanner
comes up with
> because it identifies the many ways one decision supports others
> because it tells the replanner why some currently considered
alternative was previously rejected (and usually is still bad)
> because it saves time in rejustifying unchanged parts of the plan
WORSE:
> it fails to establish a coherent picture around each idea, since
the units are atomic, the pointers bring in clusters, but most
trains of thought are linear when being developed or absorbed
> currently, the replanner needs to absorb and organize mentally the things
kludge spits out at him before he can deal with them
> thus, although the plan rationale is structured, the structure
used doesn't help him solve his problem
> data get lost and mangled from protocol to items file
> the process is hard, unsystematic, error-prone
> the uniform & simple type of rationale structure with a list of
pros & cons can't convey which of the supports was most influential,
which least, etc., but conveys the misimpression of equal importance
POTENTIALLY BETTER:
> if it provides a linearized readable explanation of why choices were made
> i would like to see a "movie" of the evolution of the plan,
what Keith called the rationale for the rationale
> if it provides a linearized set of alternatives for each choice and
makes it easy to see the pros and cons of each
> if it organizes the plan into a hierarchy of subplans,
the rationale into a hierarchy of goal-achievement proofs,
the assumptions into a hierarchy of inherited assumptions informing each
phase of planning (hence some temporally related collection of
plan rationale parts),
the alternatives for each plan element with their corresponding effects
(goal/constraint attainment/failure)
> if articulation were systematic
> if people could find the answers to their questions
HOW TO IMPROVE THE EXPERIMENT
> make the replanner autonomous
> make the items in the rationale self-explanatory
> give the replanner software training and clear instructions
> use ourselves as subjects rather than others
> divide into two groups then transfer to the others' problems
> take a part of the planners' workbench as the task
> prescribe replanning strategies
> build abstractions into the plan & rationale
-------
Date: 16 Apr 1981 1037-PST
From: Keith Wescourt <WESCOURT>
Subject: Homework
To: Planner: ;
QUESTION:
Is our current system, KLUDGE, for describing plans better
than a raw protocol?
Before considering the pros and cons of Kludge vs the protocol,
I think it is important to note several facts:
(1) The protocol we have is a very poor one relative to what a
protocol could be. Not that we did try hard, but the coverage
and detail suffer in comparison to what a trained stenographer
could have captured. Therefore, the limitations of the present
protocol may not all generalize and its strengths may have the
potential for further enhancement.
(2) However, if the protocol were more detailed, it would also be
longer and thus less manageable. This would be aggravated in the
protocol of planning sessions for a more complex problem.
Therefore, comparisons of the current protocol with Kludge depend
on the extent of this particular exercise and may not generalize
to smaller or larger scale planning.
(3) Since, the database we used in the current exercise with
Kludge was almost entirely based on the protocol, the use of
Kludge inherited some of the defects of the protocol.
PRO the PROTOCOL:
(1) The obvious: the protocol contains more information. We got
most of the facts and reasoning from the protocol into the rationale
items, but there is other transitional information-- e.g., statements
of questions raised by group members-- that provides context lacking
in the rationale database.
(2) In general, the protocol better conveys some aspects of the
structure of the rationale for plan steps. First, in the protocol you
can see whether a plan step was determined by a generate-and-test
method or by a specify-and-search method. By generate-and-test, I
mean that a tentative plan step was initially generated from a single
goal/contraint; for example, it is a route segment that connects two points
the planned course should reach. That plan step is then "tested" by
an attempt to generate rationale that supports the conclusion that it
satisfies/does-not-violate other goals/constraints. Specify-and-search
on the other hand, involves first stating a rationale involving
multiple goals/constaints and then looking for plan step consistent with
that rationale. Too much shouldn't be made of this distinction, since
the two techniques chain together; it is probably better to think of
a general split of rationalizing that takes place before or after a
tentative plan step is generated. I think the importance of knowing
this distribution for replanning is that it helps indicate the
likeliest ways to change plan steps without perturbing other parts of the
plan. For the most part, it is easier to change plan steps along
lines that have to do with the rationale following a plan step
determined by generate-and-test.
(3) Even if you don't believe the preceding claim, there is a more
general advantage of having the temporal information in the protocol.
The order of rationale development for a plan step conveys which
assertions were most critical for supporting or rejecting a conclusion.
In fact, the complexity of the trade-off between the pros and cons
for a plan step is much more obvious. Thus, in replanning, if one has
the protocol it is easier to see which goals/constraints it is most important
for modified plan steps to satisfy.
(4) The protocol better shows the evolution of the plan. You not only
know which plan steps and rationale are in and out, but when they
went in or out relative to other plan steps. Knowing this dependency
information allows one to use some simple heuristics about which
changes during replanning are least likely to interact with the
remainder of the plan.
PRO KLUDGE and its rationale database.
(1) The obvious: once you have a feeling for the Gestalt of the
problem and the concepts/vocabulary of the rationale database, it
is much easier to retrieve items about specific concepts and to
trace the full set of assumptions underlying the acceptance or exclusion
of a plan step. For simply searching, the Kludge software is much
superior to examining the protocol, even if one has the protocol
in a regular editor and can bounce around looking for strings.
In addition, the rationale file provides a much more explicit representation
of the arguments that the raw protocol. As the raw protocol progresses,
assumptions for similar types of arguments are often not repeated.
Unless one has very comprehensive mental picture of the entire
protocol, then it is easy to miss that a plan step has some rationale
that is not articulated in the protocol at the point where the
plan step is proposed. The coding of the rationale items and their
relationships made all the implicit rationale explicit for Kludge.
(2) While the protocol seems better for seeing which assumptions/assertions
are most vital to deriving a specific plan step, Kludge is much
better for determining which assumptions/assertions are vital because they
are involved in the derivation of several seemingly disjoint plan steps.
Thus, for example, during replanning, if one is contemplating a change
to a plan step that would cause a goal or constraint to no longer
be satisfied, then one can easily check (via ramify) whether there are
remaining plan steps that still satisfy it and thereby make the
proposed change acceptable (e.g., if you want to change a route segment
that has a potential water stop, you can check to see if the
adjacent route segments have alternative water stops in their supporting
rationale). To summarize, Kludge is better than the protocol for
determining those relationships between rationale and plan steps and
between plan steps that are not tied to the temporal structure of
the planning process (and protocol).
RECOMMENDATIONS
(1) It might be worth considering whether one wants to view protocols
and Kludge-like software are mutually exclusive. They seem to have
complementary features. Besides, for the foreseeable future I see
no way of going from planning to encoded rationale without a protocol,
unless we determine that planning must be done in a structured environment
which includes rationale elicitation. There are problems with keeping
protocols around, however. They are long, especially if they are
properly recorded and if they are for problems of greater scope than
the one we considered in our exercise. Reading the protocol may thus
be costly and less effective for the replanners.
(2) I see a couple of alternatives for improving Kludge to provide
the information one can get from the protocol. As long as a protocol
is around, I see the simplest alternative to be adding pointers from
encoded rationale items back the protocol and providing a way
within Kludge to retrieve the actual protocol text from which encoded
plan steps and supporting arguments were drawn. In a sense we have this
in a rudimentary form now, because most of the item names reference
lines in the protocol; one can therefore go from Kludge output back
to the protocol to selectively review the full context of rationale.
However, this is clumsy. I can easily see protocol pointers in each
rationale item that allow the user to jump into an editor/scroller
at the proper place in the protocol to more fully explore a bit
of "raw" rationale. A second, harder alternative would be to directly
encode the temporal structure of rationale into the encoded rationale
database. This might include adding temporal pointers between the
items used to rationalize a plan step or another rationale item (for
multi-level rationales). It might include annotating each item with
a "priority" tag indicating it's degree of importance in a particular
argument. Representing this additional knowledge may not be very easy,
particularly for items that appear in multiple arguments. In addition,
representing changes in the importance of an item within a rationale
over time would be hard I think. In general, I guess what I see as
necessary is a full history mechanism for representing not just the
final role of each item in the encoded rationale, but a representation
of its role at each point during the evolution of the plan. I claim
that such a history may not be particularly important for verifying
whether the paln is still valid before executing it, but is very
important for replanning to keep the replanners from duplicating
errors the original planners already recognized and eliminated.
-------
∂17 Apr 1981 1228-PST RICK Planners' Workbench project-plan for remainder of FY81
To: bill, randvax!norm at RAND-UNIX, greiner, randvax!barbara at RAND-UNIX
cc: rick, wescourt
Folks:
Here is my cut at the project-plan. When time permits,
I will encode it into a plan rationale.
In the meantime, read it, digest it, ponder it. Guide your
behavior so that it's in accordance with the plan thrust or initiate
plan changes.
We will meet 1:30 Friday May 8 to discuss the eventual form of
this plan.
I hope it suits you. It attempts to reflect your interests
and strengths, but it's just an initial guess at those.
Rick
----------------------
0<RICK.PLANNER>WORKBENCH.TODO.2 17-Apr-81 12:18:44, Edit by RICK
Goals: (Level-1)
> Demonstrate a workbench by Oct 1 or soon thereafter
> Everybody doing a piece of the coding and using the system
> A usable tool
> Complete our Kludge experiments by June 1
> Complete our Successor design by Aug 1
(Level-2)
> Demonstrate a workbench by Oct 1 or soon thereafter
> Good conceptual retrieval
> Easy conceptual extension
> Good plan rationale entry, especially proof construction
> Some graphic display
> Some graphic editing
> Reasonably complex problem
> Answer whether plan rationale violated by changed assumption
> Answer "WHY?" any action is being done
> Answer "WHY NOT?" any action is not being done
> Answer "WHY SHOULD NOT?" an action be done
> Answer "WHY OUGHT?" an action be done
> Answer "What must be done to do X"
> Answer what conditions some proposed action needs to satisfy
> Identify unproved plan parts
> Tell how a proprosed action undoes the plan proof
> Attribute, date, and mark items in/out
> Everybody doing a piece of the coding and using the system
> Each person has an area of responsibility
> Each specifies what he/she wants to produce
> Collaboration to integrate designs
> A usable tool
> Viable, friendly, moderate speed and size
> A good self-contained demo & tutorial
> Complete our Kludge experiments by June 1
> Rerun the experiment
> Run the experiment on ourselves
> Complete our Successor (Workbench-0) design by Aug 1
> Define a coherent but subset of capabilities do-able in 2 months
> Define a useful example
(Level-3 through Level-5)
> Good conceptual retrieval
> Preprocess items to attach conceptual descriptions to them
> This is the parsing dual of macro expansion now used
> For each match, recode as parse tree
> Match conceptual questions only with conceptual descriptions
> Match the parse tree for conceptual questions with
precomputed conceptual match parse trees
> E.g., WHAT DOES norm like? --> Norm likes ?X -->
(norm|norman|norm shapiro)
NOUN-VERB-Connectors
(likes|wants|prefers|desires|seeks)
VERB-OBJECT-connectors
(to VERB-PHRASE(?X) | NOUN-PHRASE(?X))
> Highlight match
> A body of standard questions (parameterized question types)
> Allow a flexible language for describing patterns of both
conceptual and string matching
> These may be conjoined, with conceptual matching first,
then string matching on appropriately highlighted parts
Parse sentences
> Syntactic matches
> Easy conceptual extension
> Good plan rationale entry, especially proof construction
> How about a structure like the one I'm using?
> Indentation means subgoal/action for outer block
> Need hierarchies of assumptions to avoid repetition
> Need implicit satisfaction of constraints by all actions
> Most choices are better than alternatives because the alts don't
satisfy one of the implicit constraints--which one?
> Some graphic display
> If we use this type of structure, indented material doesn't
show up without zooming in for detail (corresponds to generations)
> Varying attributes/dates/designations of items => varying symbols
> Text abstraction (to limit area reqts)
> Some graphic editing
> Adding or deleting items in 2-d, changing their text
> Reasonably complex problem
> Plan for the workbench itself
> good for everyone!
> Emergency replanning task
> A military one
> Something with the B1 bombers vs. cruise missile vs. 747s etc.
> Use the bike trip as a transfer test source
> Answer whether plan rationale violated by changed assumption
> Propagate change through the net, semi-automatically
> Some machine inference
> Time scheduling operations and constraints
> Parameterize time and ramify time
> Answer "WHY?" any action is being done
> It's necessary for one of the goals, constraints, or precondition
for some action (e.g. like the next one in sequence)
> It helps achieve one of these, better than the alternatives
> Answer "WHY NOT?" any action is not being done
> It violates or hurts one of the goals, constraints, or preconditions
for some action
> It's worse than an alternative
> Answer "WHY SHOULD NOT?" an action be done
> Like WHY NOT? for hypothetical action
> Answer "WHY OUGHT?" an action be done
> Like WHY for hypothetical action
> Answer "What must be done to do X"
> Preconditions & constraints for that X satisfies
> Special case, what must be done before/after doing x
> Special case, what requirements arise if we want to do x
> Answer what conditions some proposed action needs to satisfy
> Same as "What must be done to do X" for a hypothetical X
> Identify unproved plan parts
> Tell how a proprosed action undoes the plan proof
> Combine WHY SHOULD NOT,ramify change & identify unproved plan parts
> Attribute, date, and mark items in/out
> What was the plan on day 1? On day 2?
> What was in on day 1 but out on day 2? WHY NOT each of these?
> Who made the plan, what's the rationale according to various people?
Initial proposed areas of principal personal responsibilities:
barbara: articulation, abstraction & rationale
=> define the structure of a "good" rationale
bill: elicitation, dimensions,constraints, strategies/tactics of the plan
=> these must fit the structure of a good "rationale"
norm: database, ramification, all interfaces, system design,
integration, configuration control,
graphics & other forms of presentation
keith: plan evolution (retro & pro-active) & question-answering
rick: conceptual encoding & retrieval
System development parts and issues
> Machines/systems and lack of high bandwidth comm
> Graphics--generate to AED which will be on pdp 20
> Plan entry and modification
>> unix, english parser, yacc, lex
> Data base
>> unix, berkeley's rdb system (isis)
> Conceptual encoding
>> lisp, ellie/yacc
> Query language
>> lisp, ellie/yacc
> Searching
>> rll, lisp, grep, isis
> Display
>> small talk, megatek, which processor?
> Intermediate files
> auto file mgt
>> tops20, unix
> helpful ways to find, label, manage working files
>> tops20, unix
> Hardcopy
> session traces
>> unix, laser
> plans
>> flowcharting software
> rationales
>> flowcharting software
> graphics
>> device?
> Multiperson sharing
>> rosie front-end & rosie-to-rosie or unix/tops20
∂6 May 1981 1538-PDT BILL workbench.todo homework
To: rick
cc: norm at RAND-AI, barbara, wescourt
Additions to my copy of WORKBENCH.TODO are indicated below by ":>"
in lieu of ">". The suggestion that we (1) anchor what we do at one
end with protocols and rationale and at the other end by standard
planning tools, such as Gantt charts, and (2) use a Rand management
plan other than the workbench plan for the demo.
WORKBENCH.TODO
Goals: (Level-1)
> Demonstrate a workbench by Oct 1 or soon thereafter
> Everybody doing a piece of the coding and using the system
> A usable tool
> Complete our Kludge experiments by June 1
> Complete our Successor design by Aug 1
(Level-2)
> Demonstrate a workbench by Oct 1 or soon thereafter
> Good conceptual retrieval
> Easy conceptual extension
> Good plan rationale entry, especially proof construction
> Some graphic display
> Some graphic editing
> Reasonably complex problem
> Answer whether plan rationale violated by changed assumption
> Answer "WHY?" any action is being done
> Answer "WHY NOT?" any action is not being done
> Answer "WHY SHOULD NOT?" an action be done
> Answer "WHY OUGHT?" an action be done
> Answer "What must be done to do X"
> Answer what conditions some proposed action needs to satisfy
> Identify unproved plan parts
> Tell how a proprosed action undoes the plan proof
> Attribute, date, and mark items in/out
> Everybody doing a piece of the coding and using the system
> Each person has an area of responsibility
> Each specifies what he/she wants to produce
> Collaboration to integrate designs
> A usable tool
> Viable, friendly, moderate speed and size
> A good self-contained demo & tutorial
:> Usable by some specific group of planners
> Complete our Kludge experiments by June 1
> Rerun the experiment
> Run the experiment on ourselves
> Complete our Successor (Workbench-0) design by Aug 1
> Define a coherent but subset of capabilities do-able in 2 months
> Define a useful example
(Level-3 through Level-5)
> Good conceptual retrieval
> Preprocess items to attach conceptual descriptions to them
> This is the parsing dual of macro expansion now used
> For each match, recode as parse tree
> Match conceptual questions only with conceptual descriptions
> Match the parse tree for conceptual questions with
precomputed conceptual match parse trees
> E.g., WHAT DOES norm like? --> Norm likes ?X -->
(norm|norman|norm shapiro)
NOUN-VERB-Connectors
(likes|wants|prefers|desires|seeks)
VERB-OBJECT-connectors
(to VERB-PHRASE(?X) | NOUN-PHRASE(?X))
> Highlight match
> A body of standard questions (parameterized question types)
> Allow a flexible language for describing patterns of both
conceptual and string matching
> These may be conjoined, with conceptual matching first,
then string matching on appropriately highlighted parts
Parse sentences
> Syntactic matches
> Easy conceptual extension
> Good plan rationale entry, especially proof construction
> How about a structure like the one I'm using?
> Indentation means subgoal/action for outer block
> Need hierarchies of assumptions to avoid repetition
> Need implicit satisfaction of constraints by all actions
> Most choices are better than alternatives because the alts don't
satisfy one of the implicit constraints--which one?
> Some graphic display
> If we use this type of structure, indented material doesn't
show up without zooming in for detail (corresponds to generations)
> Varying attributes/dates/designations of items => varying symbols
> Text abstraction (to limit area reqts)
> Some graphic editing
> Adding or deleting items in 2-d, changing their text
> Reasonably complex problem
> Plan for the workbench itself
> good for everyone!
> Emergency replanning task
> A military one
> Something with the B1 bombers vs. cruise missile vs. 747s etc.
> Use the bike trip as a transfer test source
> Answer whether plan rationale violated by changed assumption
> Propagate change through the net, semi-automatically
> Some machine inference
> Time scheduling operations and constraints
> Parameterize time and ramify time
> Answer "WHY?" any action is being done
> It's necessary for one of the goals, constraints, or precondition
for some action (e.g. like the next one in sequence)
> It helps achieve one of these, better than the alternatives
> Answer "WHY NOT?" any action is not being done
> It violates or hurts one of the goals, constraints, or preconditions
for some action
> It's worse than an alternative
> Answer "WHY SHOULD NOT?" an action be done
> Like WHY NOT? for hypothetical action
> Answer "WHY OUGHT?" an action be done
> Like WHY for hypothetical action
> Answer "What must be done to do X"
> Preconditions & constraints for that X satisfies
> Special case, what must be done before/after doing x
> Special case, what requirements arise if we want to do x
> Answer what conditions some proposed action needs to satisfy
> Same as "What must be done to do X" for a hypothetical X
> Identify unproved plan parts
> Tell how a proprosed action undoes the plan proof
> Combine WHY SHOULD NOT,ramify change & identify unproved plan parts
> Attribute, date, and mark items in/out
> What was the plan on day 1? On day 2?
> What was in on day 1 but out on day 2? WHY NOT each of these?
> Who made the plan, what's the rationale according to various people?
:> Usable by some specific group of planners
:> Group other than the core group
:> Much greater credibility among potential users/clients
:> Broaden the base of planning inputs to workbench design
:> Not much harder to do than demo based on workbench planning
:> Doesn't preclude using workbench for workbench planning
:> Management planners
:> Structure of management plans is well-known and fairly well
standardized
:> At the highest level, output should be practically identical to
planning output presently used
:> Highest level output should be in form of Gantt charts,
manpower utilization charts, and (possibly) critical path
networks
:> Identical-to-normal output makes planners comfortable,
feeling in-control, and makes any use of workbench entirely
voluntary--hence no opposition to workbench
:> Identical-to-normal output is immediately and unquestionably
useful and usable
:> Presently used planning methods have limitations workbench could
help overcome
:> Changing dates means redrawing charts; graphic capability to
do this would be welcomed
:> Shifting resources impacts several planning tools/displays;
modifying the workbench database could kill several birds with
one stone and assure consistency among plan parts/displays
:> Presently used methods entirely devoid of supporting rationale
:> Keeping plan current is often considered not worth the effort;
challenge to workbench would be to make plan maintenance
worth the effort
:> Management support is needed to fund workbench research;
management is already familiar with strengths and weaknesses of
current management planning; easiest demo for funders to relate to
:> It is essential that the program/project manager personally want
to use our highest level (identical-to-normal) output in managing
:> In-house Rand planners
:> Would facilitate close liaison between planners and workbench
researchers
:> Possibly ICJ research program planners
:> ICJ would probably benefit from improved planning
:> ICJ has to replan as result of revised funding and outcomes
of research projects
:> Rationale for ICJ research is complex, hard to untangle,
easy to lose sight of as things change
:> To the extent that ICJ is using some AI (Waterman/Peterson
work on modeling legal systems using ROSIE), there is some
sympathy with AI applications
:> Bill thinks Steve Carroll might be receptive to the idea,
possibly partially funding Bill during the summer to implement
it
:> Demonstration of workbench being a demonstration of ICJ
management planning might, in itself, be useful to ICJ, for it
to use as a demonstration, showing synergism of ICJ with Rand
:> ICJ not military--drawback from ARPA perspective
:> Possibly Strategic Assessment Center planners
:> SAC currently expects funding for June-September on-board in
June
:> SAC has already gone through several replanning phases; more
to be expected
:> There are divergent views on what SAC should be doing
:> Divergent views within Rand
:> Divergent views among clients
:> Workbench could help sort them out; help tailor briefings
to specific audiences
:> SAC has some sympathy with AI applications, using game-playing
in Red/Blue agents (Gillogly) and ROSIE heuristic modeling in
Scenario agent (Dewar/Schwabe)
:> Demonstration of workbench being also a demonstration of
SAC management planning might, in itself, be useful to SAC,
for it to use as a demonstration
:> SAC military--advantage from ARPA perspective
Initial proposed areas of principal personal responsibilities:
barbara: articulation, abstraction & rationale
=> define the structure of a "good" rationale
bill: identify planning/replanning output that
(1) could be produced by workbench
(2) would be on 8 1/2 x 11 inch paper
(3) would be nearly identical to planning output
planners would use without workbench
(by end of July)
code software to prepare the above identical-to-normal
planning/replanning output from workbench-produced files,
using software existing on VAX as much as possible
(August-September)
elicit SAC planning/replanning items and rationale from interviews
and existing memos; work with other core group members getting
rationale into proper form
(May-June)
elicit ongoing SAC planning/replanning information
(July-September; possibly SAC funded)
help identify capabilities that would be useful to management
planners in linking task plans, resource plans, and research plans
and that the workbench (demo version or subsequent version) could
provide; develop and maintain a "wish list"
(May-September)
norm: database, ramification, all interfaces, system design,
integration, configuration control,
graphics & other forms of presentation
keith: plan evolution (retro & pro-active) & question-answering
rick: conceptual encoding & retrieval
System development parts and issues
> Machines/systems and lack of high bandwidth comm
> Graphics--generate to AED which will be on pdp 20
> Plan entry and modification
>> unix, english parser, yacc, lex
> Data base
>> unix, berkeley's rdb system (isis)
> Conceptual encoding
>> lisp, ellie/yacc
> Query language
>> lisp, ellie/yacc
> Searching
>> rll, lisp, grep, isis
> Display
>> small talk, megatek, which processor?
> Intermediate files
> auto file mgt
>> tops20, unix
> helpful ways to find, label, manage working files
>> tops20, unix
> Hardcopy
> session traces
>> unix, laser
> plans
>> flowcharting software
> rationales
>> flowcharting software
> graphics
>> device?
> Multiperson sharing
>> rosie front-end & rosie-to-rosie or unix/tops20
∂8 May 1981 1320-PDT Keith Wescourt <WESCOURT> PROJECT PLAN HW
To: Bill, Greiner, Rick, Wescourt, Barbara, Norm at RAND-AI, Mike
0<WESCOURT.PLANNER>PROJECT-PLAN..5 8-May-81 13:17:32, Edit by WESCOURT
0<RICK.PLANNER>WORKBENCH.TODO.2 17-Apr-81 12:18:44, Edit by RICK
KW's Notation:
/kw == kw's rationale statements
{kw: ....} == kw's questions and suggested revisions
Goals: (Level-1)
> Demonstrate a workbench by Oct 1 or soon thereafter
> Everybody doing a piece of the coding and using the system
> A usable tool
> Complete our Kludge experiments by June 1
> Complete our Successor design by Aug 1
(Level-2)
> Demonstrate a workbench by Oct 1 or soon thereafter
> Good conceptual retrieval
/kw searching for raw strings is inadequate
/kw conceptual structure must be accessible to encoder & retriever
> Easy conceptual extension
/kw encoder & retriever will develop new useful conceptual distinctions
as the workbench is used
/kw it is impractical for users to manually attach new conceptual
knowledge to existing items
> Good plan rationale entry, especially proof construction
/kw users cannot be trusted to enter consistent structures without
without aiding
> Some graphic display
/kw we believe that graphics are necessary to make stored rationales
understandable
> Some graphic editing
/kw given graphic display, graphic editing is a natural medium for
changing stored structures
> Reasonably complex problem
/kw outsiders won't be interested with successes on toy problems
/kw we want to work on something meaningful to us
/kw a complex problem is needed for us to discover the important
issues in building and using a workbench
> Answer whether plan rationale violated by changed assumption
> Answer "WHY?" any action is being done
> Answer "WHY NOT?" any action is not being done
> Answer "WHY SHOULD NOT?" an action be done
> Answer "WHY OUGHT?" an action be done
> Answer "What must be done to do X"
> Answer what conditions some proposed action needs to satisfy
> Identify unproved plan parts
> Tell how a proprosed action undoes the plan proof
> Attribute, date, and mark items in/out
/kw origin of plan contents and knowledge of plan evolution are
important for understanding and evaluating it-- they supply
additional, implicit rationale
> Everybody doing a piece of the coding and using the system
> Each person has an area of responsibility
/kw each person has some different skills and interests
/kw the rand environment stresses individual accountability
/kw we think we will be more productive by subdividing responsibility
> Each specifies what he/she wants to produce
/kw this will make division of responsibility more meaningful
/kw we think we should be able to pursue our own interests within
the context of the project
> Collaboration to integrate designs
/kw given division of responsibility and individual choice of direction,
negotiation between individuals is essential to build a working
system
> A usable tool
> Viable, friendly, moderate speed and size
/kw the system must make a good impression on outsiders who use it
/kw we won't enjoy working with a slow, clumsy-to-use system
> A good self-contained demo & tutorial
/kw we don't want to be burdened with personally acquainting people
with the system
/kw people are impressed by systems that they can understand and learn
to use without hand-holding
/kw a system is not complete without documentation
> Complete our Kludge experiments by June 1
> Rerun the experiment
/kw we don't feel we learned enough from the first experiment
/kw the software wasn't adequate for the first experiment
/kw we think we can do better the second time around
> Run the experiment on ourselves
/kw we all need to know how to use the software well
/kw we all need to be able to appreciate the system from the
users' point of view
/kw we all need to understand the cognitive/emotional aspects of
trying to do disciplined replanning.
> Complete our Successor (Workbench-0) design by Aug 1
> Define a coherent but subset of capabilities do-able in 2 months
/kw we are shooting for a Oct 1 demonstration
/kw we already have a set of objectives we know we cannot fully
satisfy by Oct 1
> Define a useful example
/kw we think that we cannot yet create a problem-independent
workbench so we need have the application clearly in mind as
we develop this prototype
(Level-3 through Level-5)
> Good conceptual retrieval
> Preprocess items to attach conceptual descriptions to them
/kw preprocessing will make retrieval faster at run-time
> This is the parsing dual of macro expansion now used
> For each match, recode as parse tree
> Match conceptual questions only with conceptual descriptions
> Match the parse tree for conceptual questions with
precomputed conceptual match parse trees
> E.g., WHAT DOES norm like? --> Norm likes ?X -->
(norm|norman|norm shapiro)
NOUN-VERB-Connectors
(likes|wants|prefers|desires|seeks)
VERB-OBJECT-connectors
(to VERB-PHRASE(?X) | NOUN-PHRASE(?X))
> Highlight match
> A body of standard questions (parameterized question types)
/kw we can't support arbitrary questions
/kw we think we have identified the most useful/frequent types
of questions
> Allow a flexible language for describing patterns of both
conceptual and string matching
/kw the conceptual hierarchy will probably not be sufficient by
itself
/kw the user will be able to access the database and identify
raw strings useful for search
> These may be conjoined, with conceptual matching first,
then string matching on appropriately highlighted parts
Parse sentences
> Syntactic matches {kw: what does this mean?}
/kw we should support sysntactic as well as semantic variations
> Easy conceptual extension
{kw: this seems like it will be tricky with preprocessing}
> Good plan rationale entry, especially proof construction
> How about a structure like the one I'm using?
{kw: How about using interactive menus driven by "planning grammars"}
> Indentation means subgoal/action for outer block
> Need hierarchies of assumptions to avoid repetition
/kw it is tedious to manually replicate the same structure for
several different plan steps
> Need implicit satisfaction of constraints by all actions
{kw: I'm not sure what this means}
> Most choices are better than alternatives because the alts don't
satisfy one of the implicit constraints--which one?
/kw representation of some things by exclusion rather than inclusion
has certain advantages
> Some graphic display
> If we use this type of structure, indented material doesn't
show up without zooming in for detail (corresponds to generations)
/kw we think people generally want to limit or at least control the
level of detail they must see at any time
> Varying attributes/dates/designations of items => varying symbols
/kw people need powerful simple ways of distinguishing classes of
information
> Text abstraction (to limit area reqts)
> Some graphic editing
> Adding or deleting items in 2-d, changing their text
> Reasonably complex problem
> Plan for the workbench itself
> good for everyone!
> Emergency replanning task
/kw emergency replanning is a very motivating problem for most people
at Rand
/kw we could all feel like we were contributing to society
/kw emergency (re)planners need and WANT help now
/kw emergency planning organizations seem to lack some features
we feel may reduce the effectiveness of the workbench for
other organizations (e.g., the tendency to hide reasons from
others)
> A military one
/kw there is a lot of military expertise at rand
/kw the DoD is paying for this research right now
/kw the military needs planning help
/kw ~ it's hard to get access to military data for real,
interesting problems
/kw ~ most of us would rather not work on classified problems
> Something with the B1 bombers vs. cruise missile vs. 747s etc.
> Use the bike trip as a transfer test source
> Answer whether plan rationale violated by changed assumption
> Propagate change through the net, semi-automatically
> Some machine inference
> Time scheduling operations and constraints
> Parameterize time and ramify time
> Answer "WHY?" any action is being done
> It's necessary for one of the goals, constraints, or precondition
for some action (e.g. like the next one in sequence)
> It helps achieve one of these, better than the alternatives
> Answer "WHY NOT?" any action is not being done
> It violates or hurts one of the goals, constraints, or preconditions
for some action
> It's worse than an alternative
> Answer "WHY SHOULD NOT?" an action be done
> Like WHY NOT? for hypothetical action
> Answer "WHY OUGHT?" an action be done
> Like WHY for hypothetical action
> Answer "What must be done to do X"
> Preconditions & constraints for that X satisfies
> Special case, what must be done before/after doing x
> Special case, what requirements arise if we want to do x
> Answer what conditions some proposed action needs to satisfy
> Same as "What must be done to do X" for a hypothetical X
> Identify unproved plan parts
> Tell how a proprosed action undoes the plan proof
> Combine WHY SHOULD NOT,ramify change & identify unproved plan parts
> Attribute, date, and mark items in/out
> What was the plan on day 1? On day 2?
> What was in on day 1 but out on day 2? WHY NOT each of these?
> Who made the plan, what's the rationale according to various people?
Initial proposed areas of principal personal responsibilities:
barbara: articulation, abstraction & rationale
=> define the structure of a "good" rationale
bill: elicitation, dimensions,constraints, strategies/tactics of the plan
=> these must fit the structure of a good "rationale"
norm: database, ramification, all interfaces, system design,
integration, configuration control,
graphics & other forms of presentation
keith: plan evolution (retro & pro-active) & question-answering
{kw: tutorial, too. I see the order/priority of my tasks to
be question-answering; paln evolution; tutorial}
rick: conceptual encoding & retrieval
System development parts and issues
> Machines/systems and lack of high bandwidth comm
> Graphics--generate to AED which will be on pdp 20
> Plan entry and modification
>> unix, english parser, yacc, lex
{kw: >> menus}
> Data base
>> unix, berkeley's rdb system (isis)
> Conceptual encoding
>> lisp, ellie/yacc
> Query language
>> lisp, ellie/yacc
{kw: >> menus}
> Searching
>> rll, lisp, grep, isis
> Display
>> small talk, megatek, which processor?
> Intermediate files
> auto file mgt
>> tops20, unix
> helpful ways to find, label, manage working files
>> tops20, unix
> Hardcopy
> session traces
>> unix, laser
> plans
>> flowcharting software
> rationales
>> flowcharting software
> graphics
>> device?
> Multiperson sharing
>> rosie front-end & rosie-to-rosie or unix/tops20
-------
∂18 May 1981 1155-PDT Keith Wescourt <WESCOURT>
Revisions to CORE project plan thru end of FY 81
To: Bill, Greiner, Rick, Wescourt, Barbara, Norm at RAND-AI, Mike
GENERAL GOALS/CONSTRAINTS
[Rick]
Consolidate and package our efforts to date. If we find the project
is not to be continued, what can we present to the AF and the world as
our accomplishments.
{
We have a responsibility to the AF.
We want to be able to coherently describe what we've done to
colleagues.
We MAY need it to help secure further support.
}
[Rick]
Secure support for further work.
{
We want to continue the project.
}
[Bill, Rick]
Associate the project with a real-world planning task either internal
or external to Rand, but external to our own immediate self-interests
(it can affect us, but should be someone elses problem and
responsibility).
{
Such a problem will motivate us to do better work.
Such a problem will give the project credibility and visibility that will
enhance its prospects for having a real outcome and our own
careers.
}
[Rick]
Maintain the productivity and happiness of project staff
{
Promote the cohesiveness and stability of the project.
Increase the likelihood that the project will generate something
worthwhile.
Satisfy the personal goals of project staff
}
GROUP ACTIVITIES
[June 15, Rick]
Articulate a motivation for what we are doing that anticipates the
questions we have had directed at us in previous briefings and
discussions. Each staff member must learn that entire motivation.
What is the problem?
Why do we think a primarily technological solution can solve
it?
Even if we can generate a solution, why do we think we can get
anyone to use it?
{
We need to be able to determine whether our efforts are making any
progress.
We should share a common perspective on what we are doing.
Everyone should be able to brief the project to clients/visitors.
}
[?date?, Norm]
Evolve the existing Kludge system into a demo that we feel comfortable
showing to people outside Rand.
{
The demo is a vital part of our reporting requirements.
The demo is a vital part of our efforts to get continued support.
The existing demo is inadequate from many perspectives.
}
[July 1, Keith]
Expand our goal for the workbench to include it's use as a tool to
monitor and control the execution of parameterized (conditional)
plans. Develop additional motivation and determine any additional
features the Workbench might need to support such application.
{
Potential supporters of the research seem to have less trouble with
this type of use than with replanning.
Little in the way of additional system functions may be needed to support
this type of use.
}
[July 1, Barbara]
Develop a consensus about how the workbench ought to be used within
existing organizational planning situations OR how organizational
planning must be changed to accomodate use of the Workbench in order
to reap its benefits. Focus on how a big plan and rationale is going
to get entered into the system in the first place.
{
It is hard for most people to imagine how this technology will be
able to work in real organizations.
If we are going to work on a real planning task, we'd better be able to
specify in detail to the organization collaborating with us how we
are going to interact with them.
The design of any further retrieval capabilities for the demo software
depends on the assumptions we can make about how much structure will
be imposed on the database at the time it is entered.
}
[July 15, Keith]
Develop a consensus about the types of queries the Workbench will be
able to support. In particular, should it directly aid decisions at
high levels of abstraction (e.g., "if I now believe X and Y, which
parts of the plan can I still use") or should it only answer questions
about the relationships between the indivdual items in the database.
{
Our present direction is toward a system that requires the end-user
to understand the database structure so he/she can translate
questions about how to replan into lower level questions about
the relationships between plan structures and then figure out how
the answers to those low-level questions bear on his/her problem.
The system might be easier to use if it could answer the more
high-level questions directly.
}
INDIVIDUAL ACTIVITIES AND SUB-TASKS
[July 15, Norm, Keith]
Re-write existing Kludge software to use existing tools like
Lex and YACC.
{
Improve scope and efficiency of "conceptual" retrieval
Make software more easily extensible
}
[?date?]
Identify and implement features of a demo that will make it
attract the uninitiated and help convince them that a real
system will be worthwhile.
Things we can do now, without more hardware:
[Norm] character graphics (e.g., to draw/edit plan/rationale structures)
[Keith] menu-driven querying and maybe entry of database items and
structure
[Keith, Barbara] on-line interactive tutorial
[Barbara, Keith] off-line tutorial reference manual
{
The demo must be usable, if only to allow demonstrations where
users can themselves discover the value of such software.
}
[July 15, Bill, Barbara, Norm]
Elicit and record an entirely new bicycle plan and rationale under
more controlled conditions.
Act as if it was the first time we were working on a problem in
this domain.
Make it longer, more complex (e.g., a multi-day trip -- norm doesn't
really have to take it).
{
After developing a consensus about how the Workbench will be used
to elicit and record rationales we need to test those ideas.
The present rationale and plan have been compromised by ad hoc,
post hoc additions required to make our initial demo do any
interesting.
We need a plan that has more contingencies/alternatives in it if the
demo is to seem non-trivial.
}
[Aug 1, Bill, Rick, Barbara]
Select a real-world planning problem and have 2 or more of the the
project staff familiarize themselves with the domain to the extent
that they can serve as articulators for planners in that domain.
Generate an a priori conceptual hierarchy (e.g., a la LEX, for the
domain)
{
Demonstrate to a would be client that we are ready to move to a
real domain.
Get a feeling for how much conceptual structure for a plan and
rationale can be defined prior to planning and thus be available
to structure the database when a plan is being developed.
Be ready to start work in the domain as soon as we secure support
for the next FY
}
-------
---------------
-------
∂25-May-81 1407 barbara at RAND-UNIX Re: Relns connecting Rationale & PlanSteps
In-reply-to: Your message of 21 May 1981 1708-PDT.
From: barbara at RAND-UNIX
Hi Russ -
I have taken the liberty of forwarding your message to the
other members of the project, so you may be hearing from them as well.
I have a few reactions to your proposals:
1. I think you did a nice job systematically enumerating many important
kinds of relationships between a HEAD and its UNDERLINGS. The bike trip
protocol (i.e., the transcript of the discussions in which we generated the
plan) contains instances of almost all of the relationships you mentioned
(although, of course, they are not all coded explicitly
in the current rationale).
2. I believe there are other potentially useful types of relationships.
Example: Structured arguments.
The protocol contains some instances of well-structured
arguments of the form: Premise A, Premise B, ..., Therefore Conclusion.
In other cases, a statement in the protocol is supported by a list
of more or less independent reasons. Some statements benefit from both
types of support and there are probably others as well.
In any case, we might want to explicate the nature of the argument
underlying a particular statement and the exact
relationships among its constituents.
Example: Domain-specific functional relationships
Resource requirements are a major consideration in the bike trip plan.
It might be useful to code them explicitly so that we could easily
answer questions like--How much money does Norm need and which parts of
the plan require cash?
3. As I understand your approach to this problem, you are trying to
enumerate a "complete" set of relationships, capable of capturing
everything planners might express during a planning episode.
Another approach would be to enumerate those relationships that
would provide useful functions during plan review, plan evaluation,
plan modification, etc. What functions will the relationships you proposed
provide? What questions will they answer?
How will they help somone understand or use the rationale?
4. Most of your assumptions (e.g., about plan versus rationale)
were correct. Your terminology is different from the Rand group's
terminology, but easy to understand.
5. Another useful "time" (in addition to plan generation and plan execution)
is plan modification time. How do we keep track of successive states
of an evolving plan and their relationships to one another?
6. General issues of timing planned actions are apt to be more complex than
"before," "after," and "until." Consider: at 5:00, during the ascent,
within 60 seconds of landing, for at least two hours.
That's all for now. I hope these comments are useful.
Barbara
∂19-Jun-81 1236 RICK at RAND-AI revised retrieval specifications
To: rdg at SU-AI, wescourt at RAND-AI, rick at RAND-UNIX
cc: rick at RAND-AI
0<RICK.PLANNER>RETRIEVAL.TODO.1 18-Jun-81 13:26:00, Edit by RICK
Things for Retrieval to do/IO specifications
Inputs that change the database
User-prerogatives:
Different users have specific rights to change kinds of
values
One kind of prerogative is the right to change item prototypes
From retrieval:default attributes for items of certain characteristics
automatic addition of pointer inverses
other consistency checks
defaults for particular users
From entry:
Enter new items
(CreateItem <proplist>)
<proplist> ::= () | (<attribute-val>..<proplist>)
<attribute-val> ::= <predef-attributes> | <undef-attributes>
<predef-attributes> ::= POINTERS <ptr-item-list>
| DESCRIPTORS <self-desc-list>
| KEYWORDS <phrase-list>
| HISTORY (<past-item-id-and-reason> <future-item-id>)
| STATUSES <status-val-list>
| ITEM←TYPES <type-list>
| NAMES <phrase-list>
| VERBATIM <sent-string>
| SYNTAX <case-frame-parse>
<undef-attributes> ::= <attribute> <value>
<self-desc-list> ::= UNIQUE←ID <item-id>
| CREATION←DATE <creation-date>
| CREATOR <creator>
<past-item-id-and-reason> ::= (<item-id> <reason-for-change-item-id>
| NIL
<reason-for-change-item-id> ::= <item-id>
<future-item-id> ::= <item-id> | NIL
<ptr-item-list> ::= () | (<pointer-val>..<ptr-item-list>)
<pointer-val> ::= <pointer> <item-reference-list>
<item-reference-list> ::= () | (<item-ref>..<item-reference-list>
(item-ref> ::= <item-id> | <item-get-fn-entry> | <item-get-fn-ret>
<item-get-fn-entry> ::= (ENTRY <retrieval-spec>)
<item-get-fn-ret> ::= (RETRIEVAL <retrieval-spec>)
<status-val-list> ::= () | (<status>..<status-val-list>)
<status> ::= IN | OUT
<type> ::= REASON | GOAL | PLAN←STEP | SPECIFICATION | DEFINITION
| ASSUMPTION | REJECTION
<phrase> ::= <regular-expression>
<case-frame-parse> ::= <recursive-property-list-of-parse>
[Multiword-atoms formed with underbars for space]
[Case decisions: input case preserved; retrieval ignores case]
Name
Attribute-values
Short printnames
status,itemtype,
descriptors (creator,date)
Text
String, parse case frames
Constraint equation
Pointed-to-items
Parameters/variables
Indirect references to items or elements of items
Immediately evaluated
Evaluated at retrieval time
Edit existing items
New version of the item
Relationship with previous versions
From Analysis:
Edit existing items (as above)
Inputs that request info from the database & outputs desired
From entry:
Input= <reference> is description of desired item
+ <desired elements>
Output = a list of ((item id, (desired elts of that item))...)
Special kind of <reference>:
All items which are in some role in some relation
(e.g., the dependent on a transitively closed inv-pro)
[Can't currently say to the syntax]
(Extract <item-spec-list> <extraction-schema>
****----****
Find <item-list> <match-spec> --> <item-id-list> [subsets the list]
Ramify <item-list> <relation> <closure-operator> --> <item-id-list> [new list]
Extract <item-list> <schema> --> <extracted-item-list>[gets att-vals of items]
<schema> = attribute-list
<item-list> ::= all-items, item-id-list
<match-spec> ::= boolean-combination-of-primitives
<primitive> ::= <element> <match-op> <term>
<element> ::= <attribute> | <ptr>
<match-op> ::= INCLUDE | INCLUDES | MENTION | MENTIONS | = | ~=
all-plan←steps, plan←steps whose date < 14 apr 81
[[match-spec itself must allow recursive specification]]
[[current syntax probably doesn't allow correctly]]
find all-items whose (pro items)'s keywords include norm
Entry produces item references both from syntax & from user requests.
Here are the kinds of references the syntax of items supports:
<elt-of-ref>is description of infor desired from desired item
<reference> ::= # <quant> <item-type> [WHOSE <element>
<match-op> <term> {<conj> WHOSE <element> <match-op> <term>}]
<elt-of-ref> ::= [<quant> <element> OF] <reference>
<match-op> <term> {<conj> WHOSE <element> <match-op> <term>} ]
<element> ::= <attribute> ATTRIBUTE | <ptr> ITEM
<quant> ::= EVERY | THE
<match-op> ::= INCLUDE | INCLUDES | MENTION | MENTIONS | = | ~=
Examples of syntactic references and elt-of-refs
[the following now parses]
the keywords attribute of every item whose keywords attribute include norm
[the following do not now parse, but probably should]
the keywords attribute of the item whose pro ITEM mention [*]any person
... [*] has a subject = Norm &
has a verb = does travel
every item whose pro-1* item = item 2901.1
[asterisk here means transitive closure; what about "+" ?]
∂TO Keith, Greiner (12:05 29 June)
Data for Retrieval
Keith -
I'm all set to start coding the level-0 implementation of
the "retriever", and now need data to work on.
Rather than cons-up some random examples, I figured I'd snatch some of
the existing messages now in workbench, massage that into a format
corresponding to our interface agreement, and store that sort of stuff.
Unfortunately that lacks things like the parse-tree, and keywords, ...
The other problem is I don't really know what sort of inquiries will
be made, into this DB.
So now the question: Have you already made up such a file -- consisting
of a string of commands of the sort Entry would send to Retrieval?
If not, could you create such a file, which I could use for my design?
-----
That file could be in the format
(CreateItem (TYPE REASON STATUS IN KEYWORDS (Fred Mary) ...))
(Find ALL-ITEMS (AND (EQUAL STATUS IN)
(EQUAL TYPE REASON)
(INCLUDE KEYWORDS Martha)))
...
Thanks,
Russ
∂29-Jun-81 1259 Keith Wescourt <WESCOURT at RAND-AI> Re: Data for Retrieval
To: RDG at SU-AI
cc: keith at RAND-AI, greiner at RAND-AI
In-Reply-To: Your message of 29-Jun-81 1205-PDT
Russ,
I'd like to oblige you, but am doing my own coding/example generation
for the input syntax. We've all agreed that everyone should make
up their own test data for now, so I'm afraid you'll just have
to fake it from the existing items on the VAX even if they don't
have parse-tress, keywords, etc. I don't think that anything
ENTRY will be send you for retrieval purposes will key on parse-trees
anyway. FGor purposes of testing you should add keywords, etc
to your test items as you see fit-- imagine the types of references
to existing items you would like to make if you were entering
a rationale...
I'll let you know as soon as I have something you can use. Right
now I'm still trying to define and implement a parsable input grammar
using ELLIE.
Keith
-------
∂24 Jul 1981 1112-PDT <WESCOURT> Re: Minor changes to Entry/Retrieval Interface Specification
To: GREINER
cc: rick
In-Reply-To: Your message of 23-Jul-81 1211-PDT
∂ 23 Jul 1981 1211-PDT GREINER Minor changes to Entry/Retrieval Interface Specification
To: wescOURT
cc: greiNER, rick
Greetings! How is ENTRYing going?
I've implemented a parsable syntax in Ellie. It still has a few glitches
handling compound relative clauses, but I'm passing them over to
work on the semantics of the productions-- i.e., building the CreateItems
sentences for you.
I'm starting to get the retrieving to turn over; and have some small
proposals to proffer:
1) It might be easier to send several new items at once -- using a
CreateItems function. Inverse pointers, and other KB maintanence will
be performed at the conclusion of creating all the items. See the file
<core>To-Retr.From-Entry to see examples of this.
Yes, I'll be parsing a "buffer" full of items at a time and won't "send"
them to you until they all parse correctly.
2) As RETRIEVAL is ultimately responsible for giving each item a unique
id, it seems silly for ENTRY to send along (what it claims to be) a
UNIQUE-ID. However it certainly is convenient to have such a handle,
to tie things (sent together in a CreateItems command) to one another.
For this purpose I propose ENTRY automatically send along its ENTRY-ID.
The "acknowledging" value then returned from the CreateItems will then
be an alist (or plist if you force me) of the form
((entry-id1 . unique-id1) (entry-id2 . unique-id2) ...(entry-idN . unique-idN))
and ENTRY will be expected to use these Unique-Ids from now on (ie
there seems no advantage to preserving these non-unique entry-ids after
this command).
Exactly. I proposed that the ID's I would be sending you would be local
to the buffer of parsed items sent at any one time. I want to use them
as the values of pointer attributes between those items in the same buffer.
The unique ID you generate will serve the same function for pointers to
items already in the database.
3) We need to establish some "quoting" conventions -- to determine whether
the values of a given attribute should be taken as is, or evaluated
at item-creation time.
It seems most POINTER values should be evaluated, and, in most cases,
all the other values should be just accepted.
I've begun to have some doubts about storing retrieval specs as pointer values
and evaluating them dynamically whenever the pointer is followed. The
major problem I see is with the back-pointers. E.g., if A has an unevaluated
"support" pointer to "every plan-step whose doer is Keith", then if
I happen to be focusing on some plan-step whose doer is Keith how can
the system efficiently find that A supports that plan-step if I ask
"what items support this plan-step?" I propose, therefore, that
for the present all "indirect" pointer values be evaluated at the
time of storage so that all the explicit pointers and backpointers can
be stored.
Should RETRIEVAL adopt these conventions:
(i) Each POINTER value will be first evaluated before storage.*,**
(ii) Every other value will be simply stored, EXCEPT when that value
is a list whose CAR is EVAL@CREATE,*** in which case, the
rest of that form is handed to the EVAL@CREATE function, which,
for now, we will assume simply EVALs it.
Notes:
* - If you want that value unevaled, just QUOTE it.
** - Using the function EVAL@END-of-CREATE delays the evaluation until
the end of this CreateItems call.
(This facilities forward referencing.)
*** - Perhaps we could define a whole class of these EVAL@←←← operators,
which indicate just when some expression should be evaluated;
and possibly how as well.
Certainly an EVAL@RETRIEVAL is essential; and there may be several
flavors of this, depending on whether the computed value should
replace the current (EVAL@RETRIEVAL ...) expression or not.
Given, my remark above, NO.
--------
Other questions:
I've been scanning the stuff in workbench at Rand-Unix,
and am please to see specifications for the task being solidified.
Shall I assume ENTRY will send me any-and-all of those attributes,
named as such?
(Or perhaps each property name will be in upper case, or ...)
Yes. I believe the syntax of the strings you get from entry will
clearly delimit attribute from attribute value. I don't know about
converting to uppercase, do you need that?
This leads to a whole other can of worms: just what should
RETRIEVAL do when finding a new property? Automatically create a
new unit for this (as I can assume no typos will get by ENTRY),
FALSE. ENTRY will interpret any word (excluding certain reserved words)
as a property name if it is in the right position.
or simply squawk? Perhaps send a query back, to confirm that
attribute is legitimate?
I prefer that third alternative -- with expectations that
ENTRY will then send back some instruction like
YES. The sentiment is that users should be able to create new
pointers or attributes on the fly. I don't like it, but if we
are going to live with it, we need to interact to filter out
typos.
Oops, that was really the Pro attribute, not Por.
Yes, create a new type of POINTER, just like Con. As you
guessed, its inverse is the same name, prefaced with -.
I just asked the user, who told me to forget that attribute.
Comments, please.
Thanks,
Russ
-------
Hope these comments help.
By the way, I currently plan to have all the RLL, ROSIE and IL
processes communicate by reading and writing strings to a
commonly mapped page(s) (emulating IPCF). A top-level executive
process will provide the user access to each sub-process directly.
If a process needs to use another, it will write an addressed
message into the mapped page and return control to the excutive.
The executive will read the address of the message, and activate
the appropriate sub-process, which will take its input from the
mapped page. Any comments on this-- I think it is a common
trick for emulating IPCF.
Keith
∂TO Wescourt, Rick 17:05 24-Jul
(Follow up)↑2
Keith -
------
Exactly. I proposed that the ID's I would be sending you would be local
to the buffer of parsed items sent at any one time. I want to use them
as the values of pointer attributes between those items in the same buffer.
The unique ID you generate will serve the same function for pointers to
items already in the database.
Any thought on how RETRIEVAL should send ENTRY the link -- info to tie
the ENTRY-ID you supply to the UNIQUE-ID I assign.
Maybe something like
(RESPONSE (Entry-Unique <entry-id1> <retr-id1>
<entry-id2> <retr-id2>
... ...
<entry-idN> <retr-idN>))
------
I've begun to have some doubts about storing retrieval specs as pointer values
and evaluating them dynamically whenever the pointer is followed. The
major problem I see is with the back-pointers. E.g., if A has an unevaluated
"support" pointer to "every plan-step whose doer is Keith", then if
I happen to be focusing on some plan-step whose doer is Keith how can
the system efficiently find that A supports that plan-step if I ask
"what items support this plan-step?" I propose, therefore, that
for the present all "indirect" pointer values be evaluated at the
time of storage so that all the explicit pointers and backpointers can
be stored.
I agree -- issues like this complicate retrieval; and mean the obvious retrieval
schemes won't work.
That "every plan-step whose doer is Keith" example seems to force
us (well, me)
to implement demons -- ie little globs of code which act, at item creation
and modification times, doing this dirty work.
I'll gladly push this task until later;
I'd like to first see how often this facility really comes up,
to decide how it should be implemented.
The nice thing about the EVAL@ convention is that it permits us the flexibility
to later on add in things which seem essential --
I will be quite surprised if we can get away with just
storing the unprocessed input value.
<<< Proposal:
Using a form like
(... Sub (EVAL@ AllUpdates
(FindAll (EQ-PROP ITEM-TYPE Plan-Step) (EQ-PROP STATUS IN))) ...)
will both
i) Determine all plan-steps which are in,
storing these as the Sub for this item, I,
and
ii) Set up a demon to monitors the items, noting each time the
status of a plan-step becomes IN.
As this happens, this item is added to I's Sub attribute,
as desired.>>>
[My next message will define retrieval language I used above.]
------
Yes. I believe the syntax of the strings you get from entry will
clearly delimit attribute from attribute value. I don't know about
converting to uppercase, do you need that?
What? My question was about the pre-defined attributes: will you use the same
names which appeared in the note from Barbara, on 16-Jul?
Will you send me AUTHOR rather than CREATOR -- or will be Author, or something
else?
Similarly should RETRIEVAL be prepared for the
Sub, -Sub, Alt, (-Alt), Req, -Req, Cor, Dep, -Dep, Pro, -Pro, Con, -Con
pointers mentioned in that message,
or for SubOrdinate, SuperOrdinate, ...?
or for SUB, -SUB, ...
Similarly will you send me "Type" or Item-Type? And will it now be singular?
Is it STATUSES or STATUS, (or Status)?
We should get together, soon, and decide on these sorts of issues.
(Side Question: Isn't Alt its own inverse? Why have -Alt?)
------
YES. The sentiment is that users should be able to create new
pointers or attributes on the fly. I don't like it, but if we
are going to live with it, we need to interact to filter out
typos.
Ah, this is another thing we should hammer out.
Do you have any suggestions on how RETRIEVAL should ask questions of ENTRY?
ENTRY should also have the option of volunteering information, perhaps using
a CreateItems-like CreateObject command.
This could then be used to define new attributes, pointers, classes, types, ...
------
By the way, I currently plan to have all the RLL, ROSIE and IL
processes communicate by reading and writing strings to a
commonly mapped page(s) (emulating IPCF). A top-level executive
process will provide the user access to each sub-process directly.
If a process needs to use another, it will write an addressed
message into the mapped page and return control to the excutive.
The executive will read the address of the message, and activate
the appropriate sub-process, which will take its input from the
mapped page. Any comments on this-- I think it is a common
trick for emulating IPCF.
The only comment I have is that this method forces us into a single-processor
mode -- there seems no way RLL could be doing some background stuff while
waiting for its next input. But for a level-1 (or are we at 2 yet?) system
this seems quite nice, and sufficient.
------
Russ
∂TO Wescourt, Rick 18:25 24-Jul
Specifications for the Find type of commands:
The command will be
(<Find?> {<spec>})
[{x} means one or more x's]
where <Find?> = FindFirst | FindAll
<spec> = <term> |
(OR {<spec>}) |
(AND {<spec>}) |
(NOT <spec>)
<term> = (EQ-PROP <Prop> <val>) |
(MEMB-PROP <Prop> <val>) |
(SPEC-PROP <Prop> <quant> <spec>) |
(PRED-PROP <Prop> <fn>) |
(PRED <fn>) |
(GEN <sexpr>)
The FindFirst command returns a single UNIQUE-ID - corresponding to the first
and presumably only) item which satisfies these constraints, or NIL.
FindAll returns a list of the UNIQUE-IDs of all items which qualify, or NIL.
Further specification:
<Prop> is any of the attributes, content or pointers,
<val> is an unevaled constant value
(possibly with certain tricks for the unusual case when
you want it evaluated now - probably not)
<fn> evaluates to a predicate function
<sexpr> is a LISP s-expression, to be evaluted,
<quant> = Any | All | None
(If Any, this suceeds when any of the list of values satisfies the predicate, <fn>;
when All, each value must satisfy <fn>,
None means all of the values must fail.
I may later get fancier, and allow numeric ranges, or statements that
as many of these as those, or ...)
Examples:
(EQ-PROP STATUS IN)
(MEMB-PROP KEYWORDS Norm)
(SPEC-PROP Pro Any (EQ-PROP AUTHOR GREINER))
ie refers to an item whose Pro pointer points to some item
whose Author is Greiner.
(PRED-PROP Pro (Either (OneOf (EQ-PROP AUTHOR GREINER))
(AllOf (EQ-PROP STATUS OUT ))))
where
(Either fn1 fn2) = fn3 => [fn3(x) = T] <=> [fn1(x) = T or fn2(x) = T];
(OneOf fn) = fn0 => [fn0(x) = T] <=> [(SOME x fn) = T];
(AllOf fn) = fn0 => [fn0(x) = T] <=> [(EVERY x fn) = T];
[x = T, here, means x is nonNIL]
-- these functions are defined in the system --
Note: EQ-PROP here evaluates to a predicate. I'l say more on that below.
(PRED-PROP Pro '(LAMBDA (val) (OR (> val 7)
(FindFirst (MEMB-PROP SUBJECT Trouble)
(MEMB-PROP TEXT Good)
(EQ-PROP ITEM-TYPE Rationale)))))
Notes: yep, you can call on FindFirst, as you could on any function.
I'll eventually decide on some global variables which will be set
to the UNIQUE-IDs of the current candidates (ie those which qualify
thus far in the query), and maybe some other values as well.
(PRED '(LAMBDA (item) ... ))
this is the ultimate catch-all -- this spec accepts all items which
which satisfy this predicate.
[Before I could say anything meaningful we have to define an attribute
retrieval function -- perhaps simply (GET <item-id> <prop>)...]
(GEN (LIST 'Rat#32))
this is for generating, rather than pruning, possible entries.
Additional notes:
There is an implicit AND-junction of the list of <spec> given
in the <Find?> statement.
------
Nuts and bolts:
The beauty of this system is that
the first 3 types of terms,
(EQ-PROP, MEMB-PROP, and SPEC-PROP)
[and some cases of PRED-PROP as well,]
can be considered as either generators or pruners.
Efficiency comes from deciding which:
Associated with each type of property will be some information
(perhaps simply previously gathered empirical evidence, or maybe some more
elaborate data for some complex symbolic reasoner,) which indicates which
way to determine the qualifying items.
I imagine the eventual algorithm will:
Scan the list of specs, determining which one serves as the best generator.
Execute that, as a generator, to get an initial set.
Subset this generated list using the conjunct of the predicates associated with
each of those remaining specs.
[They should probably first be ordered, so those which
seem most restricted appear first.]
Return that passing list - or its CAR if FindFirst is the caller.
Note that
(1) any GEN will qualify as the Generator, for obvious reasons.
(Actually the intersection of the values of all the GENs...)
(2) Properties which have pre-stored inverses are the next best candidates
for generators -- especially when that inverse is unique.
(3) If nothing even remotely qualifies as a generator, the list of all
items is used. Hopefully this wouldn't happen too often.
(4) Those logical ANDs, ORs and NOTs fit nicely into this sceme, in obvious ways.
Anyway, I wouldn't tire you with more details.
Comments?
Russ
∂TO wescourt at RAND-AI, rick at RAND-AI 14:24 29-Jul
Updated version now at [Rand-Ai]<CORE>RETRIEVAL-SYNTAX.USER [28-Sept]
Specification language to Retrieval, from Entry (and anyone else?)
Notation:
{x} means one or more x's
[x] means zero or more x's
(a . b) means (CONS a b)
(a..b) means (APPEND a b)
-- so ((p1 v1)..(p2 v2 p3 v3)) gives (p1 v1 p2 v2 p3 v3)
( and ) are LISP parentheses...
Final preliminary comment: I decided to be arcane, and revert back to
Association Lists, over Property Lists.
They make life so much easier to describe.
Later on, we can upgrade this specification to correspond to that...
ENTRY can send
<Create-Item-Spec> | <Match-Spec> | <Get-Spec> | <Put-Spec>
(and possibly <Create-Obj-Spec> and <Put-Obj-Spec>).
Enter new items
<Create-Item-Spec> ::= (CreateItems {<proplist>}) --0--
<proplist> ::= {<Attribute-val>}
<Attribute-val> ::= <Def-att/val> | <Undef-att/val>
<Def-att/val> ::= --1--
(POINTERS {<ptr-item>})
| (DESCRIPTORS {<Self-desc>})
| (KEYWORDS {<phrase>})
| (HISTORY . (<past-Item-Id-and-reason> <future-Item-Id>))
| (STATUS . <status-val>) --2--
| (TYPE . <type-val>) --3--
| (NAMES . {<phrase>}) --4--
| (TEXT . <sent-string>) --5--
| (SYNTAX . <case-frame-parse>)
<Undef-att/val> ::= (<Undef-att> . <value>)
<Self-desc> ::= --6--
(ENTRY-ID . <Item-Id> ) --7--
| (CREATION-DATE . <creation-date>)
| (AUTHOR . <creator>) --8--
<creation-date> ::= <TIME-STAMP>
<creator> ::= <USER-NAME>
<past-Item-Id-and-reason> ::=
(<Item-Id> <reason-for-change-Item-Id>)
| NIL
<reason-for-change-Item-Id> ::= <Item-Id>
<future-Item-Id> ::= NIL | <Item-Id>
<pointer-val> ::= (<Pointer> . <item-reference-list>)
<Pointer> ::= Sub | -Sub | Req | -Req | Cor | Dep | -Dep
Alt | -Alt --9--
Pro | -Pro | Con | -Con
<item-reference-list> ::=
[<Item-Id>]
| <Evaled-Match-Spec>)
<time-for-eval> ::= Create | Retrieval | End-Of-Create | Always | AllUpdates
<status-val> ::= IN | OUT
*** | <Evaled-Get-Spec>
<type-val> ::= REASON | ASSUMPTION | RULE |
MASTER | GOAL | SPECIFICATION | TASK
<Evaled-Match-Spec> ::=
(EVAL@ <time-for-eval> <Match-Spec>) --10--
<Evaled-Get-Spec> ::=
(EVAL@ <time-for-eval> (GetVal <Match-Spec> <Prop>))
Still unresolved:
<sent-string>, <phrase>, <case-frame-parse>
Notes
--0-- This function will return, as a confirmation, a list of the form
( (<entry1 . unique1) (<entry2 . unique2) ... (<entryN . uniqueN) )
where each entryI is the value of the ENTRY-ID sent over for some item,
and uniqueI is the UNIQUE-ID Retrieval has assigned this item.
--1-- We will also say
<Def-att/val> ::= (<Def-att> . <value>),
where <Def-att> ::= POINTERS | DESCRIPTORS | KEYWORDS
| HISTORY | STATUS | TYPE | NAMES | TEXT | SYNTAX
--2-- not STATUSes
--3-- not ITEM-TYPES
--4-- What is this for?
--5-- not VERBATIM
--6-- We will say
<Self-desc> ::= (<Self-att> . <value>)
where <Self-att> ::= ENTRY-ID | CREATION-DATE | AUTHOR
(see note --1-- above)
--7-- not UNIQUE-ID -- Only Retrieval can generate UNIQUE-IDs!
--8-- not CREATOR
--9-- Isn't Alt its own inverse?
--10-- This will be defined in the next part.
----------
Find existing items
<Match-Spec> ::= (<Find?> {<spec>})
<Find?> ::= FindFirst | FindAll --0--
<spec> ::= <term>
| (OR {<spec>})
| (AND {<spec>})
| (NOT <spec>)
<term> ::= (EQ-PROP <Prop> <val>)
| (MEMB-PROP <Prop> <val>)
| (SPEC-PROP <Prop> <quant> <spec>)
| (PRED-PROP <Ptr-Prop> <fn>)
| (PRED <fn>)
| (GEN <sexpr>)
<Prop> ::= <Prim-Prop>
| (Composition {<Prop>}) --1--
| (Unioning {<Prop>})
| (Intersection {<Prop>})
| (Starring <Prop> )
| (Plussing <Prop> )
<Prim-Prop> ::= <Def-att> | <Undef-att> --2--
| <Pointer> | <Self-att> | <Retrieval-att>
<Retrieval-att> ::= UNIQUE-ID
<val> is an unevaled constant value
(possibly with certain tricks for the unusual case when
you want it evaluated now - probably not)
<fn> evaluates to a predicate function
<sexpr> is a LISP s-expression, to be evaluated
<quant> = Any | All | None --3--
NOTES
--0-- The FindFirst command returns a single UNIQUE-ID
-- corresponding to the first (and presumably only) item
which satisfies these constraints, or NIL.
FindAll returns a list of the UNIQUE-IDs of all items which qualify, or NIL.
--1-- These properties are particularly useful for computing ramifications,
needed for the general retrieval mentioned below.
This list of slot combiners is NOT meant to be exhaustive -- but rather
to include the sort of general properties a ramifier might need.
--2-- I'm not sure what will happend with <Undef-att> -- probably
by now they should be defined...
--3-- If Any, this predicate succeeds when any of the list of values
satisfies the predicate, <fn>;
when All, each value must satisfy <fn>,
None means all of the values must fail.
I may later get fancier, and allow numeric ranges, or statements that
as many of these as those, or ...)
----------
Get some property of some item
<Get-Spec> ::= (Get <Item-Id> <Prop>) --0--
| (GetAll <Match-Spec> {<Prop>}) --1--
*** | (GetVal <Match-Spec> <Prop> ) --2--
NOTES
--0-- The Get command returns the value of this property of the item associated
with the UNIQUE-ID <Item-Id>.
--1-- GetAll first finds the unit(s) indicated by "evaluating" the <Match-Spec>,
then retrieves the values of their properties.
The value returned is
((Id1 v11 v12 ... v1N) (Id2 v21 v22 ... v2N) ... (IdM vM1 vM2 ... vMN) )
where IdI is the I-th id returned by Match-Spec, and vIJ is the value
of the Jth property mentioned in the {<Prop>} list, of that Ith item.
(If this <Match-Spec> returned only one item, then GetAll pretends it
got the list of that single element.)
*** --2-- GetVal is like GetAll, but returns simply
(v11 v12 ... v1N v21 v22 ... v2N ... vM1 vM2 ... vMN)
[using the notation used above]. Note it concatenates the values together.]
Ramification is nothing special now: One can specify the <Prop>
(Starring Sub) - to get all Subs, their Subs, and so on. On
talk about (Composition Sub Alt) - to get all Subs of this item's Alts;
etc.
Below I will discuss how to create new types of properties, defined as some
combination of existing properties.
----------
Modify some property of some item
<Put-Spec> ::= (<Simple-Change> <Item-Id> <Prim-Prop> <value> <Why>) --0--
| (<Mult-Change> <Match-Spec> <Prim-Prop> <value> <Why>) --1--
<Simple-Change> ::= Put | Add | Delete --2--
<Mult-Change> ::= PutAll | AddAll | DeleteAll --3--
<Why> ::= <reason-for-change-Item-Id> --4--
NOTES
--0-- These commands return the new value of this property of the item associated
with the UNIQUE-ID <Item-Id>.
--1-- These first finds the unit(s) indicated by "evaluating" the <Match-Spec>,
and then modify the values of their respective <Prim-Prop> properties.
The value returned is
((Id1 v1) (Id2 v2) ... (IdM vM))
where IdI is the I-th id returned by Match-Spec, and vI is the new
value of that property.
(If this <Match-Spec> returned only one item, these functions pretends it
got the list of that single element.)
--2-- Put stores a new value in the <Prim-Prop> property of this item;
Add adds this new value in this property of the item;
and Delete deletes this value in this property of the item.
--3-- The ___All functions do just what the corresponding ___ function did,
but does so to each result of the Match-Spec.
--4-- Why points to an item which tells why this change was made.
----------
Still to do:
1) Hammer out a syntax for defining new properties. Perhaps
(CreateObject <name> ({<slot-val>})), so we might say
(CreateObject Sub* ((Isa . (AnyPointer)) (HighLevelDefn . (Starring Sub))))
-or-
(CreateObject DueDate ((Isa . (AnyPrimitiveSlot AnyRATALEFn))
(RangeType . (FSingleton (StringType (*Test TimeStamp))))
(MakesSenseFor . (TypicalPlan-Step))))
[Yes, I know the names seem arbitrary -- we could have a host of aliases
and ways of chopping strings into smaller chunks, if you prefer.]
I'll call this still undefined specification <Create-Obj-Spec>.
Once this is done, we can consider <Put-Obj-Spec>,
and possible <Get-Obj-Spec>.)
2) How to send back and form messages, especially to confirm a new type of object
or slot; and to figure out what to do with it.
Perhaps Retrieval could send something like
(I never heard of "StartDate"; based on the context I assume it is like DueDate,
and so I propose you send back:
(CreateObject StartDate ((Isa . (AnyPrimitiveSlot AnyRATALEFn))
(RangeType . (FSingleton (StringType (*Test TimeStamp))))
(MakesSenseFor . (TypicalPlan-Step))))
)
On receiving this, ENTRY could then ask the user what he meant, and
possibly just send back a confirming "Yep", which will serve as if
Entry had sent in that entry; otherwise Entry would be forced to either
retract that last item, or to first send over a new CreateObject statement,
which Retrieval would process before returning to its suspended
offending task.
Retrieval might also send a message like
(Did you mean DueDate when you said DuDate?),
etc.
----------
Comments, suggestions, improvements?
Russ
∂TO WESCOURT (CC RICK) 11:45 11-Sept
News?
Keith -
Did my last message make sense? I'm still waiting some
confirmation that I'm at least on the right track before I proceed
implementing the RETRIEVAL part.
Also, let me know if you still want me to meander down there.
It'd be nice to know at least a week in advance -- to get good plane
tickets.
Hope all is going well there.
Russ
∂11-Sep-81 1219 Keith Wescourt Re: News?
To: RDG at SU-AI
Cc: rick
Russ,
Sorry I hadn't gotten back to you. I haven't fully gone through your
very long message in enough detail to see if it helps me solve the
problem I'm working on with the entry parser. Yes, I do want you to
come down here. Next week, Thur & Fri would be preferable. What
I'd plan is for us to intersperse individual work and short meetings
in order to make the interface between entry and retrieval operational
by the time you left. Is this agreeable?
Keith
∂TO WESCOURT (CC RICK) 18:43 11-Sept
All set
Sounds fine and dandy to me. I'll be at Rand next Thursday and Friday,
the 17th & 18th of September. Is there anything you want me to bring?
(Perhaps a few copies of the RLL preliminary proto-primer?)
It would be really nice if we can get Retrieval to turn over by next
week. I'm getting a bit of pressure to start serious thesis work,
and want to be sure I'm on no one's critical path when I begin that
pursuit (more-or-less) full time.
See you soon,
Russ
∂11-Sep-81 2018 Keith Wescourt Re: All set
To: RDG at SU-AI
Cc: rick
Very good. See you on Thursday. I will keep all of
Thursday and Friday clear of other commitments and can work
on Thursday evening if we need to.
Keith